home *** CD-ROM | disk | FTP | other *** search
- What's left to do -*- outline -*-
-
- * Next API break:
- ** gcry_ac_io_t
- Remove use of anonymous union.
- ** gcry_ac
- Consider to remove it.
-
- * udiv-qrnbd.o should get build as *.lo [HPUX]
-
- * Allow operation using RSA keys consisting of the OpenSSL keys.
- This requires the introduction of a parameter names (say) U which
- is calculated according to OpenSSL/PKCS#1 rules.
-
- * Add a warning to the manual, to check that libgcrypt actually has
- been compiled with thread support when used by a threaded
- application.
-
- * linker script test
- Write an autoconf test to check whether the linker supports a
- version script.
-
- * Add attributes to the MPI functions.
-
- * cipher/pubkey.c and pubkey implementaions.
- Don't rely on the secure memory based wiping function but add an
- extra wiping.
-
- * update/improve documentation
- ** it's outdated for e.g. gcry_pk_algo_info.
- ** document algorithm capabilities
- ** Init requirements for random
- The documentation says in "Controlling the library" that some
- functions can only be used at initialization time, but it does not
- explain what that means. Initialization is a multi-step procedure:
- First the thread callbacks have to be set up (optional), then the
- gcry_check_version() function must be called (mandatory), then
- further functions can be used.
-
- The manual also says that something happens when the seed file is
- registered berfore the PRNG is initialized, but it does not say how
- one can guarantee to call it early enough.
-
- Suggested fix: Specify initialization time as the time after
- gcry_check_version and before calling any other function except
- gcry_control().
-
- All functions which modify global state without a lock must be
- documented as "can only be called during initialization time" (but
- see item 1). Then the extraneous calls to _gcry_random_initialize
- in gcry_control() can be removed, and the comments "not thread
- safe" in various initialization-time-only functions like
- _gcry_use_random_daemon become superfluous.
-
- * Use builtin bit functions of gcc 3.4
-
- * Consider using a daemon to maintain the random pool
- [Partly done] The down side of this is that we can't assume that the
- random has has always been stored in "secure memory". And we rely
- on that sniffing of Unix domain sockets is not possible. We can
- implement this simply by detecting a special prefixed random seed
- name and divert in this case to the daemon. There are several
- benefits with such an approach: We keep the state of the RNG over
- invocations of libgcrypt based applications, don't need time
- consuming initialization of the pool and in case the entropy
- collectros need to run that bunch of Unix utilities we don't waste
- their precious results.
-
- * Out of memory handler for secure memory should do proper logging
-
- There is no shortage of standard memory, so logging is most likely
- possible.
-
- * mpi_print does not use secure memory
- for internal variables.
-
- * gcry_mpi_lshift is missing
-
- * Add OAEP
-
- * gcryptrnd.c
- Requires a test for pth [done] as well as some other tests.
-
- * secmem.c
- Check whether the memory block is valid before releasing it and
- print a diagnosic, like glibc does.
-
- * threads
- ** We need to document fork problems
- In particular that reinitialization is required in random.c
- However, there is no code yet to do it.
-
- * Tests
- We need a lot more tests. Lets keep an ever growing list here.
- ** Write tests for the progress function
- ** mpitests does no real checks yet.
- ** pthreads
- To catch simple errors like the one fixed on 2007-03-16.
- ** C++ tests
- We have some code to allow using libgcrypt from C++, so we also
- should have a test case.
-
- * Use aliases for symbol instead of the wrappers in visibility.c.
-